<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html lang="en"><head><title>Simple Update Protocol</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="description" content="Simple Update Protocol">
<meta name="generator" content="xml2rfc v1.34pre2 (http://xml.resource.org/)">
<style type='text/css'><!--
        body {
                font-family: verdana, charcoal, helvetica, arial, sans-serif;
                font-size: small; color: #000; background-color: #FFF;
                margin: 2em;
        }
        h1, h2, h3, h4, h5, h6 {
                font-family: helvetica, monaco, "MS Sans Serif", arial, sans-serif;
                font-weight: bold; font-style: normal;
        }
        h1 { color: #900; background-color: transparent; text-align: right; }
        h3 { color: #333; background-color: transparent; }

        td.RFCbug {
                font-size: x-small; text-decoration: none;
                width: 30px; height: 30px; padding-top: 2px;
                text-align: justify; vertical-align: middle;
                background-color: #000;
        }
        td.RFCbug span.RFC {
                font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, verdana, sans-serif;
                font-weight: bold; color: #666;
        }
        td.RFCbug span.hotText {
                font-family: charcoal, monaco, geneva, "MS Sans Serif", helvetica, verdana, sans-serif;
                font-weight: normal; text-align: center; color: #FFF;
        }

        table.TOCbug { width: 30px; height: 15px; }
        td.TOCbug {
                text-align: center; width: 30px; height: 15px;
                color: #FFF; background-color: #900;
        }
        td.TOCbug a {
                font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, sans-serif;
                font-weight: bold; font-size: x-small; text-decoration: none;
                color: #FFF; background-color: transparent;
        }

        td.header {
                font-family: arial, helvetica, sans-serif; font-size: x-small;
                vertical-align: top; width: 33%;
                color: #FFF; background-color: #666;
        }
        td.author { font-weight: bold; font-size: x-small; margin-left: 4em; }
        td.author-text { font-size: x-small; }

        /* info code from SantaKlauss at http://www.madaboutstyle.com/tooltip2.html */
        a.info {
                /* This is the key. */
                position: relative;
                z-index: 24;
                text-decoration: none;
        }
        a.info:hover {
                z-index: 25;
                color: #FFF; background-color: #900;
        }
        a.info span { display: none; }
        a.info:hover span.info {
                /* The span will display just on :hover state. */
                display: block;
                position: absolute;
                font-size: smaller;
                top: 2em; left: -5em; width: 15em;
                padding: 2px; border: 1px solid #333;
                color: #900; background-color: #EEE;
                text-align: left;
        }

        a { font-weight: bold; }
        a:link    { color: #900; background-color: transparent; }
        a:visited { color: #633; background-color: transparent; }
        a:active  { color: #633; background-color: transparent; }

        p { margin-left: 2em; margin-right: 2em; }
        p.copyright { font-size: x-small; }
        p.toc { font-size: small; font-weight: bold; margin-left: 3em; }
        table.toc { margin: 0 0 0 3em; padding: 0; border: 0; vertical-align: text-top; }
        td.toc { font-size: small; font-weight: bold; vertical-align: text-top; }

        ol.text { margin-left: 2em; margin-right: 2em; }
        ul.text { margin-left: 2em; margin-right: 2em; }
        li      { margin-left: 3em; }

        /* RFC-2629 <spanx>s and <artwork>s. */
        em     { font-style: italic; }
        strong { font-weight: bold; }
        dfn    { font-weight: bold; font-style: normal; }
        cite   { font-weight: normal; font-style: normal; }
        tt     { color: #036; }
        tt, pre, pre dfn, pre em, pre cite, pre span {
                font-family: "Courier New", Courier, monospace; font-size: small;
        }
        pre {
                text-align: left; padding: 4px;
                color: #000; background-color: #CCC;
        }
        pre dfn  { color: #900; }
        pre em   { color: #66F; background-color: #FFC; font-weight: normal; }
        pre .key { color: #33C; font-weight: bold; }
        pre .id  { color: #900; }
        pre .str { color: #000; background-color: #CFF; }
        pre .val { color: #066; }
        pre .rep { color: #909; }
        pre .oth { color: #000; background-color: #FCF; }
        pre .err { background-color: #FCC; }

        /* RFC-2629 <texttable>s. */
        table.all, table.full, table.headers, table.none {
                font-size: small; text-align: center; border-width: 2px;
                vertical-align: top; border-collapse: collapse;
        }
        table.all, table.full { border-style: solid; border-color: black; }
        table.headers, table.none { border-style: none; }
        th {
                font-weight: bold; border-color: black;
                border-width: 2px 2px 3px 2px;
        }
        table.all th, table.full th { border-style: solid; }
        table.headers th { border-style: none none solid none; }
        table.none th { border-style: none; }
        table.all td {
                border-style: solid; border-color: #333;
                border-width: 1px 2px;
        }
        table.full td, table.headers td, table.none td { border-style: none; }

        hr { height: 1px; }
        hr.insert {
                width: 80%; border-style: none; border-width: 0;
                color: #CCC; background-color: #CCC;
        }
--></style>
</head>
<body>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<table summary="layout" width="66%" border="0" cellpadding="0" cellspacing="0"><tr><td><table summary="layout" width="100%" border="0" cellpadding="2" cellspacing="1">
<tr><td class="header">Network Working Group</td><td class="header">P. Buchheit</td></tr>
<tr><td class="header">Internet-Draft</td><td class="header">FriendFeed</td></tr>
<tr><td class="header">Intended status: Experimental</td><td class="header">D. Clinton, Ed.</td></tr>
<tr><td class="header">Expires: July 5, 2009</td><td class="header">Google</td></tr>
<tr><td class="header">&nbsp;</td><td class="header">January 2009</td></tr>
</table></td></tr></table>
<h1><br />Simple Update Protocol<br />draft-clinton-sup-current</h1>

<h3>Status of this Memo</h3>
<p>
This Internet-Draft is submitted to IETF in full
conformance with the provisions of BCP&nbsp;78 and BCP&nbsp;79.</p>
<p>
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups.
Note that other groups may also distribute working documents as
Internet-Drafts.</p>
<p>
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any time.
It is inappropriate to use Internet-Drafts as reference material or to cite
them other than as &ldquo;work in progress.&rdquo;</p>
<p>
The list of current Internet-Drafts can be accessed at
<a href='http://www.ietf.org/ietf/1id-abstracts.txt'>http://www.ietf.org/ietf/1id-abstracts.txt</a>.</p>
<p>
The list of Internet-Draft Shadow Directories can be accessed at
<a href='http://www.ietf.org/shadow.html'>http://www.ietf.org/shadow.html</a>.</p>
<p>
This Internet-Draft will expire on July 5, 2009.</p>

<h3>Copyright Notice</h3>
<p>
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors.  All rights reserved.</p>
<p>
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document.  Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.</p>

<h3>Abstract</h3>

<p>
	This specification defines the Simple Update Protocol, a
	mechanism by which content publishers can signal to 
	consumers that certain resources have been updated.
      
</p>
<h3>Editorial Note</h3>

<p>
	To provide feedback on this Internet-Draft, join the
	<a href='http://friendfeed.com/rooms/simple-update-protocol'>Simple Update Protocol room</a> on FriendFeed.  [Ed: We
	  may need/want to create a mailing list for this going
	  forward.]
      
</p><a name="toc"></a><br /><hr />
<h3>Table of Contents</h3>
<p class="toc">
<a href="#anchor1">1.</a>&nbsp;
Introduction<br />
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#anchor2">1.1.</a>&nbsp;
Notational Conventions<br />
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#anchor3">1.2.</a>&nbsp;
Design Considerations<br />
<a href="#anchor4">2.</a>&nbsp;
Overview<br />
<a href="#updates-document">3.</a>&nbsp;
Updates Document<br />
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#anchor5">3.1.</a>&nbsp;
The 'updates' field<br />
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#anchor6">3.2.</a>&nbsp;
The 'period' field<br />
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#anchor7">3.3.</a>&nbsp;
The 'since_time' field<br />
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#anchor8">3.4.</a>&nbsp;
The 'updated_time' field<br />
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#anchor9">3.5.</a>&nbsp;
The 'available_periods' field<br />
<a href="#resource-token">4.</a>&nbsp;
Resource Token<br />
<a href="#update-token">5.</a>&nbsp;
Update Token<br />
<a href="#discovery">6.</a>&nbsp;
Discovery<br />
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#updates-link-header">6.1.</a>&nbsp;
Updates Link Header<br />
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#updates-link-element">6.2.</a>&nbsp;
Updates Link Element<br />
<a href="#anchor10">7.</a>&nbsp;
Examples<br />
<a href="#anchor11">8.</a>&nbsp;
Security Considerations<br />
<a href="#iana">9.</a>&nbsp;
IANA Considerations<br />
<a href="#rfc.references1">10.</a>&nbsp;
References<br />
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#rfc.references1">10.1.</a>&nbsp;
Normative References<br />
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#rfc.references2">10.2.</a>&nbsp;
Informative References<br />
<a href="#anchor14">Appendix&nbsp;A.</a>&nbsp;
Acknowledgements<br />
<a href="#rfc.authors">&#167;</a>&nbsp;
Authors' Addresses<br />
</p>
<br clear="all" />

<a name="anchor1"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.1"></a><h3>1.&nbsp;
Introduction</h3>

<p>
	SUP (Simple Update Protocol) consists of a notification format
	called an <a class='info' href='#updates-document'>Updates
	Document<span> (</span><span class='info'>Updates Document</span><span>)</span></a> that content publishers can use to alert
	consumers that one or more resources have been recently
	changed.  Clients can subsequently poll a single Updates
	Document rather than each underlying resource individually and
	thus decrease both the latency in discovering recent changes
	and the total amount of bandwidth and time consumed.
      
</p>
<a name="anchor2"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.1.1"></a><h3>1.1.&nbsp;
Notational Conventions</h3>

<p>
	  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
	  "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
	  and "OPTIONAL" in this document are to be interpreted as
	  described in <a class='info' href='#RFC2119'>[RFC2119]<span> (</span><span class='info'>Bradner, S., &ldquo;Key words for use in RFCs to Indicate Requirement Levels,&rdquo; March&nbsp;1997.</span><span>)</span></a>.
	
</p>
<a name="anchor3"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.1.2"></a><h3>1.2.&nbsp;
Design Considerations</h3>

<p>
	  Updates Documents are designed to be easy for publishers to
          create, and increase in benefit as the number of underlying
          resources and the number of consumers grow.  Similarly,
          consumers that poll for a large number of resources from a
          given publisher, such as blog aggregators, feed readers,
          or intermediary publishers, will benefit from polling a
          publisher's Updates Document before retrieving each
          underlying resource individually.
	
</p>
<a name="anchor4"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.2"></a><h3>2.&nbsp;
Overview</h3>

<p>
	Publishers of URI-addressable resources may associated a
	semi-unique opaque identifier, called
	a <a class='info' href='#resource-token'>Resource Token<span> (</span><span class='info'>Resource Token</span><span>)</span></a>, with
	each underlying resource.  The publisher signals the existence
	of these Resource Tokens via a discovery mechanism during the
	retrieval of the resource, either within the resource itself
	(the <a class='info' href='#updates-link-element'>Updates Link
	Element<span> (</span><span class='info'>Updates Link Element</span><span>)</span></a>) or as meta-data associated with the response
	(the <a class='info' href='#updates-link-header'>Updates Link
	Header<span> (</span><span class='info'>Updates Link Header</span><span>)</span></a>).  The publisher may then create a
	URI-addressable <a class='info' href='#updates-document'>Updates
	Document<span> (</span><span class='info'>Updates Document</span><span>)</span></a> that informs consumers which resources, as
	identified by Resource Tokens, have been recently modified.
      
</p>
<a name="updates-document"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.3"></a><h3>3.&nbsp;
Updates Document</h3>

<p>
	An Updates Document consists of a URI-addressable resource of
	type 'application/json' containing a single top-level
	<a class='info' href='#RFC4627'>JSON Object<span> (</span><span class='info'>Crockford, D., &ldquo;The application/json Media Type for JavaScript Object Notation (JSON),&rdquo; July&nbsp;2006.</span><span>)</span></a> [RFC4627], mapping a set
	of well-known keys to well-defined values, as defined
	below.
      
</p>
<p>
	Consumers SHOULD ignore any unanticipated keys in the JSON
	dictionary and SHOULD continue to parse all anticipated keys
	as specified.
      
</p>
<p>
	The overall structure of the Updates Document is as follows:
      
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>{
    "updates": [ ... ],
    "period": ...,
    "since_time": ...,
    "updated_time": ...,
    "available_periods": { ... },
}</pre></div>
<a name="anchor5"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.3.1"></a><h3>3.1.&nbsp;
The 'updates' field</h3>

<p>
	  A <a class='info' href='#RFC4627'>JSON List<span> (</span><span class='info'>Crockford, D., &ldquo;The application/json Media Type for JavaScript Object Notation (JSON),&rdquo; July&nbsp;2006.</span><span>)</span></a> [RFC4627] of two-element
	  JSON Lists, each containing the tuple
	  (<a class='info' href='#resource-token'>Resource
	  Token<span> (</span><span class='info'>Resource Token</span><span>)</span></a>, <a class='info' href='#update-token'>Update
	  Token<span> (</span><span class='info'>Update Token</span><span>)</span></a>).
	
</p>
<p>
	  This field is REQUIRED. It MAY contain an empty list if no
	  resources have been updated in the given interval.
	
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>"updates": [
    ["14ea1a46", "16NV"],
    ["a2f57d4b", "16Nx"],
    ["584c7e6c", "16NV"]
]</pre></div>
<a name="anchor6"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.3.2"></a><h3>3.2.&nbsp;
The 'period' field</h3>

<p>
	  A positive integer representing the the duration of time
	  under consideration in this Updates Document, in seconds.
	
</p>
<p>
	  This field is REQUIRED.
	
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>"period": 60</pre></div>
<a name="anchor7"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.3.3"></a><h3>3.3.&nbsp;
The 'since_time' field</h3>

<p>
	  An <a class='info' href='#RFC3339'>[RFC3339]<span> (</span><span class='info'>Klyne, G., Ed. and C. Newman, &ldquo;Date and Time on the Internet: Timestamps,&rdquo; July&nbsp;2002.</span><span>)</span></a> formatted string representing
	  the start time of the interval covered by this Updates
	  Document.
	
</p>
<p>
	  This field is REQUIRED.
	
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>"since_time": "2009-01-06T00:48:38Z"</pre></div>
<a name="anchor8"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.3.4"></a><h3>3.4.&nbsp;
The 'updated_time' field</h3>

<p>
	  An <a class='info' href='#RFC3339'>[RFC3339]<span> (</span><span class='info'>Klyne, G., Ed. and C. Newman, &ldquo;Date and Time on the Internet: Timestamps,&rdquo; July&nbsp;2002.</span><span>)</span></a> formatted string representing
	  the end time of the interval covered by this Updates
	  Document.
	
</p>
<p>
	  This field is REQUIRED.
	
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>"updated_time": "2009-01-06T00:50:48Z"</pre></div>
<p>
	  The delta in seconds between the 'start_time' and the
	  'updated_time' fields MUST be equal to or greater than the
	  duration indicated by the 'period' field.
        
</p>
<a name="anchor9"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.3.5"></a><h3>3.5.&nbsp;
The 'available_periods' field</h3>

<p>
	  A JSON Object mapping time periods (in seconds) to URLs
	  where an additional Updates Documents of the corresponding
	  duration may be found.
	
</p>
<p>
	  This field is OPTIONAL.
	
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>"available_periods": {
    "60": "http://example.com/sup.json?seconds=60",
    "300": "http://example.com/sup.json?seconds=300",
    "600": "http://example.com/sup.json?seconds=600"
}</pre></div>
<a name="resource-token"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.4"></a><h3>4.&nbsp;
Resource Token</h3>

<p>
	A Resource Token is a short opaque string used to identify a
	individual URI-addressable resource.  Each unique underlying
	resource MUST always map to a single, stable Resource Token,
	but different resources MAY occasionally share the same
	Resource Token.
      
</p>
<p>
	Consumers SHOULD NOT attempt to parse or interpret the
	contents of the Resource Token.  Clients SHOULD maintain a
	mapping of Resource Tokens to resource URIs is established via
	the <a class='info' href='#discovery'>Discovery<span> (</span><span class='info'>Discovery</span><span>)</span></a> mechanisms
	defined below.
      
</p>
<p>
	A valid Resource Token is a non-empty string of no more than
	128 characters composed of ASCII letters, numbers, or hyphens
	(regex [a-zA-Z0-9\-]), and are produced via the following
	rules, as defined by the
	<a class='info' href='#RFC5234'>augmented BNF<span> (</span><span class='info'>Crocker, D. and P. Overell, &ldquo;Augmented BNF for Syntax Specifications: ABNF,&rdquo; January&nbsp;2008.</span><span>)</span></a> [RFC5234] syntax.
      
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>resource_token = 1*128(CHAR / DIGIT / "-")</pre></div>
<a name="update-token"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.5"></a><h3>5.&nbsp;
Update Token</h3>

<p>
	The Update Token is a short opaque string used to disambiguate
	distinct updates to a URI-addressable resource.  In practice,
	the last update timestamp of the resource or its ETag is a
	suitable identifier, but clients SHOULD NOT attempt to parse
	or interpret the contents of the string.
      
</p>
<p>
	A valid Update Token is a non-empty string of no more than 128
	characters composed of ASCII letters, numbers, or hyphens
	(regex [a-zA-Z0-9\-]), and are produced via the following
	rules, as defined by the
	<a class='info' href='#RFC5234'>augmented BNF<span> (</span><span class='info'>Crocker, D. and P. Overell, &ldquo;Augmented BNF for Syntax Specifications: ABNF,&rdquo; January&nbsp;2008.</span><span>)</span></a> [RFC5234] syntax.
      
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>update_token = 1*128(CHAR / DIGIT / "-")</pre></div>
<a name="discovery"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.6"></a><h3>6.&nbsp;
Discovery</h3>

<p>
	This section discusses how a publisher signals the existence
	of an Updates Document and how the publisher establishes the
	relationship between the semi-unique Resource Token and an
	underlying URI-addressable resource.
      
</p>
<p>
	Publishers SHOULD announce the availability of an Updates
	Document and associate the underlying resource with a
	corresponding Resource Token via
	the <a class='info' href='#updates-link-header'>Updates Link
	Header<span> (</span><span class='info'>Updates Link Header</span><span>)</span></a>.  If the underlying resource is an XML-based
	document, the publisher may additionally include
	a <a class='info' href='#updates-link-element'>Updates Link
	Element<span> (</span><span class='info'>Updates Link Element</span><span>)</span></a> within the document itself.
      
</p>
<p>
	Use of the Updates Link Header is RECOMMENDED as it is
	applicable to all resources published over HTTP, but consumers
	SHOULD be prepared for the presence of the Updates Link
	Element in addition to, or instead of, the Updates Link
	Header, when the underlying resource is a XML-based document.
      
</p>
<a name="updates-link-header"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.6.1"></a><h3>6.1.&nbsp;
Updates Link Header</h3>

<p>
	  Responses to <a class='info' href='#RFC2616'>HTTP<span> (</span><span class='info'>Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, &ldquo;Hypertext Transfer Protocol -- HTTP/1.1,&rdquo; June&nbsp;1999.</span><span>)</span></a> [RFC2616] requests for
	  resources SHOULD include a <a class='info' href='#RFC2616'>HTTP
	  Response Header<span> (</span><span class='info'>Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, &ldquo;Hypertext Transfer Protocol -- HTTP/1.1,&rdquo; June&nbsp;1999.</span><span>)</span></a> [RFC2616] of 'Link' to signal both the URI at
	  which the <a class='info' href='#updates-document'>Updates
	  Document<span> (</span><span class='info'>Updates Document</span><span>)</span></a> may be polled and the
	  semi-unique <a class='info' href='#resource-token'>Resource
	  Token<span> (</span><span class='info'>Resource Token</span><span>)</span></a> of the resource being retrieved.
	
</p>
<p>
	  The 'rel' value of the Link header is defined as
	  follows:  [Pending IANA consideration]
	
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>updates</pre></div>
<p>
	  The 'type' value of the Link header is defined as follows:
	
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>application/json</pre></div>
<p>
	  The 'href' value of the Link header is produced via
	  the via the following rules, as defined by the
	  <a class='info' href='#RFC5234'>augmented BNF<span> (</span><span class='info'>Crocker, D. and P. Overell, &ldquo;Augmented BNF for Syntax Specifications: ABNF,&rdquo; January&nbsp;2008.</span><span>)</span></a> [RFC5234] syntax, the URI
	  production grammar defined in <a class='info' href='#RFC3986'>[RFC3986]<span> (</span><span class='info'>Berners-Lee, T., Fielding, R., and L. Masinter, &ldquo;Uniform Resource Identifier (URI): Generic Syntax,&rdquo; January&nbsp;2005.</span><span>)</span></a>, and
	  the above grammar defining
	  the <a class='info' href='#resource-token'>'resource_token'<span> (</span><span class='info'>Resource Token</span><span>)</span></a>
	  production.
	
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>updates_document_uri =
    scheme ":" hier-part [ "?" query ] [ "#" resource_token ]</pre></div>
<p>
	  The complete value of the 'Link' header conform with the conventions
	  formalized in
	  <a class='info' href='#I-D.nottingham-http-link-header'>[I&#8209;D.nottingham&#8209;http&#8209;link&#8209;header]<span> (</span><span class='info'>Nottingham, M., &ldquo;Link Relations and HTTP Header Linking,&rdquo; November&nbsp;2008.</span><span>)</span></a> according
	  to the following production rules, as defined by the
	  <a class='info' href='#RFC5234'>augmented BNF<span> (</span><span class='info'>Crocker, D. and P. Overell, &ldquo;Augmented BNF for Syntax Specifications: ABNF,&rdquo; January&nbsp;2008.</span><span>)</span></a> [RFC5234] syntax, the URI
	  production grammar defined in <a class='info' href='#RFC3986'>[RFC3986]<span> (</span><span class='info'>Berners-Lee, T., Fielding, R., and L. Masinter, &ldquo;Uniform Resource Identifier (URI): Generic Syntax,&rdquo; January&nbsp;2005.</span><span>)</span></a> and
	  the 'updates_document_uri' production as defined above.
	
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>link_rel_value = "updates"
link_type = "application/json"
link_title = "Updates Document"
link_header = "Link:" 1*SP updates_document_uri *SP ";" 1*LWSP
    "rel=" DQUOTE link_rel_value DQUOTE ";" 1*LWSP
    "type=" DQUOTE link_type DQUOTE ";" 1*LWSP
    "title=" DQUOTE link_title DQUOTE</pre></div>
<p>
	  For example, the following 'Link' header refers to a Updates 
	  Document at 'http://example.com/sup.json' and indicates that the
	  Resource Token of the resource being returned is '4496672d'.
	
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>Link: &lt;http://example.com/sup.json#4496672d&gt;;
    rel="updates";
    type="application/json";
    title="Updates Document"</pre></div>
<a name="updates-link-element"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.6.2"></a><h3>6.2.&nbsp;
Updates Link Element</h3>

<p>
	  In addition to, or instead of,
	  the <a class='info' href='#updates-link-header'>Updates Link
	  Header<span> (</span><span class='info'>Updates Link Header</span><span>)</span></a>, XML-based resources MAY include
	  an <a class='info' href='#RFC4287'>Atom Syndication Format<span> (</span><span class='info'>Nottingham, M. and R. Sayre, &ldquo;The Atom Syndication Format,&rdquo; December&nbsp;2005.</span><span>)</span></a> [RFC4287]
	  'atom:link' element to signal both the URI at which
	  the <a class='info' href='#updates-document'>Updates Document<span> (</span><span class='info'>Updates Document</span><span>)</span></a> may be
	  retrieved and the <a class='info' href='#resource-token'>Resource
	  Token<span> (</span><span class='info'>Resource Token</span><span>)</span></a> associated with the containing document.
	
</p>
<p>
	  The 'rel' value of the atom:link element is defined as
	  follows:  [Pending IANA consideration]
	
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>updates</pre></div>
<p>
	  The 'type' value of the atom:link element is defined as follows:
	
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>application/json</pre></div>
<p>	
	  The 'href' value of the atom:link element is produced via
	  the via the following rules, as defined by the
	  <a class='info' href='#RFC5234'>augmented BNF<span> (</span><span class='info'>Crocker, D. and P. Overell, &ldquo;Augmented BNF for Syntax Specifications: ABNF,&rdquo; January&nbsp;2008.</span><span>)</span></a> [RFC5234] syntax, the URI
	  production grammar defined in <a class='info' href='#RFC3986'>[RFC3986]<span> (</span><span class='info'>Berners-Lee, T., Fielding, R., and L. Masinter, &ldquo;Uniform Resource Identifier (URI): Generic Syntax,&rdquo; January&nbsp;2005.</span><span>)</span></a>, and
	  the above grammar defining
	  the <a class='info' href='#resource-token'>'resource_token'<span> (</span><span class='info'>Resource Token</span><span>)</span></a> production.
	
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>updates_document_uri =
    scheme ":" hier-part [ "?" query ] [ "#" resource_token ]</pre></div>
<p>
	  For example, the following 'atom:link' element refers to a
	  Updates Document at 'http://example.com/sup.json' and
	  indicates that the Resource Token of the containing document
	  is '4496672d'.
	
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>&lt;link xmlns="http://www.w3.org/2005/Atom"
      rel="updates"
      type="application/json"
      title="Updates Document"
      href="http://example.com/sup.json#4496672d"/&gt;</pre></div>
<a name="anchor10"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.7"></a><h3>7.&nbsp;
Examples</h3>

<p>
	The following is a sample Updates Document that indicates that
	five distinct URI-addressable resources were updated in the
	interval between 1:14:35 and 1:16:45.
      
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>{
  "available_periods": {
    "60": "http://example.com/sup.json?seconds=60",
    "300": "http://example.com/sup.json?seconds=300",
    "600": "http://example.com/sup.json?seconds=600"
  },
  "period": 60,
  "since_time": "2009-01-06T01:14:35Z",
  "updated_time": "2009-01-06T01:16:45Z",
  "updates": [
    [
      "4496672d",
      "16fg"
    ],
    [
      "e8d50639",
      "16fg"
    ],
    [
      "e7cd6949",
      "16eA"
    ],
    [
      "1d8274dd",
      "16eA"
    ],
    [
      "19ab3751",
      "16eA"
    ],
  ]
}</pre></div>
<a name="anchor11"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.8"></a><h3>8.&nbsp;
Security Considerations</h3>

<p>
        SUP does not require that a site MUST encrypt its resource
        tokens. The resource tokens may be rendered opaque through
        strong encryption, hashing, or they may be non-opaque. In a
        scenario where a SUP document is being used to indicate that
        private or password protected resources have been updated and
        the resource tokens are insufficiently opaque (e.g. the urls
        of the resources are used as resource tokens or the resource
        tokens are rendered opaque with an algorithm that can be
        reversed in order to identify the underlying resource) then an
        attacker can build up a detailed profile of when these
        documents were updated. This profile can then be correlated
        with other data sources in order to compromise the security of
        the private or password protected resources. This is one way
        adoption of SUP can potentially weaken a site's security.
      
</p>
<a name="iana"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.9"></a><h3>9.&nbsp;
IANA Considerations</h3>

<p>
	[Ed: Draft language to propose "updates" as a IANA recognized link relation value.]
      
</p>
<a name="rfc.references"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.10"></a><h3>10.&nbsp;
References</h3>

<a name="rfc.references1"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<h3>10.1.&nbsp;Normative References</h3>
<table width="99%" border="0">
<tr><td class="author-text" valign="top"><a name="RFC2119">[RFC2119]</a></td>
<td class="author-text"><a href="mailto:sob@harvard.edu">Bradner, S.</a>, &ldquo;<a href="http://tools.ietf.org/html/rfc2119">Key words for use in RFCs to Indicate Requirement Levels</a>,&rdquo; BCP&nbsp;14, RFC&nbsp;2119, March&nbsp;1997 (<a href="ftp://ftp.isi.edu/in-notes/rfc2119.txt">TXT</a>, <a href="http://xml.resource.org/public/rfc/html/rfc2119.html">HTML</a>, <a href="http://xml.resource.org/public/rfc/xml/rfc2119.xml">XML</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC2616">[RFC2616]</a></td>
<td class="author-text"><a href="mailto:fielding@ics.uci.edu">Fielding, R.</a>, <a href="mailto:jg@w3.org">Gettys, J.</a>, <a href="mailto:mogul@wrl.dec.com">Mogul, J.</a>, <a href="mailto:frystyk@w3.org">Frystyk, H.</a>, <a href="mailto:masinter@parc.xerox.com">Masinter, L.</a>, <a href="mailto:paulle@microsoft.com">Leach, P.</a>, and <a href="mailto:timbl@w3.org">T. Berners-Lee</a>, &ldquo;<a href="http://tools.ietf.org/html/rfc2616">Hypertext Transfer Protocol -- HTTP/1.1</a>,&rdquo; RFC&nbsp;2616, June&nbsp;1999 (<a href="ftp://ftp.isi.edu/in-notes/rfc2616.txt">TXT</a>, <a href="ftp://ftp.isi.edu/in-notes/rfc2616.ps">PS</a>, <a href="ftp://ftp.isi.edu/in-notes/rfc2616.pdf">PDF</a>, <a href="http://xml.resource.org/public/rfc/html/rfc2616.html">HTML</a>, <a href="http://xml.resource.org/public/rfc/xml/rfc2616.xml">XML</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC3339">[RFC3339]</a></td>
<td class="author-text"><a href="mailto:GK@ACM.ORG">Klyne, G., Ed.</a> and <a href="mailto:chris.newman@sun.com">C. Newman</a>, &ldquo;<a href="http://tools.ietf.org/html/rfc3339">Date and Time on the Internet: Timestamps</a>,&rdquo; RFC&nbsp;3339, July&nbsp;2002 (<a href="ftp://ftp.isi.edu/in-notes/rfc3339.txt">TXT</a>, <a href="http://xml.resource.org/public/rfc/html/rfc3339.html">HTML</a>, <a href="http://xml.resource.org/public/rfc/xml/rfc3339.xml">XML</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC3986">[RFC3986]</a></td>
<td class="author-text"><a href="mailto:timbl@w3.org">Berners-Lee, T.</a>, <a href="mailto:fielding@gbiv.com">Fielding, R.</a>, and <a href="mailto:LMM@acm.org">L. Masinter</a>, &ldquo;<a href="http://tools.ietf.org/html/rfc3986">Uniform Resource Identifier (URI): Generic Syntax</a>,&rdquo; STD&nbsp;66, RFC&nbsp;3986, January&nbsp;2005 (<a href="ftp://ftp.isi.edu/in-notes/rfc3986.txt">TXT</a>, <a href="http://xml.resource.org/public/rfc/html/rfc3986.html">HTML</a>, <a href="http://xml.resource.org/public/rfc/xml/rfc3986.xml">XML</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC4287">[RFC4287]</a></td>
<td class="author-text">Nottingham, M. and R. Sayre, &ldquo;<a href="http://tools.ietf.org/html/rfc4287">The Atom Syndication Format</a>,&rdquo; RFC&nbsp;4287, December&nbsp;2005 (<a href="http://ftp.rfc-editor.org/in-notes/rfc4287.txt">TXT</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC4627">[RFC4627]</a></td>
<td class="author-text">Crockford, D., &ldquo;<a href="http://tools.ietf.org/html/rfc4627">The application/json Media Type for JavaScript Object Notation (JSON)</a>,&rdquo; RFC&nbsp;4627, July&nbsp;2006 (<a href="ftp://ftp.isi.edu/in-notes/rfc4627.txt">TXT</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC5234">[RFC5234]</a></td>
<td class="author-text">Crocker, D. and P. Overell, &ldquo;<a href="http://tools.ietf.org/html/rfc5234">Augmented BNF for Syntax Specifications: ABNF</a>,&rdquo; STD&nbsp;68, RFC&nbsp;5234, January&nbsp;2008 (<a href="ftp://ftp.isi.edu/in-notes/rfc5234.txt">TXT</a>).</td></tr>
</table>

<a name="rfc.references2"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<h3>10.2.&nbsp;Informative References</h3>
<table width="99%" border="0">
<tr><td class="author-text" valign="top"><a name="I-D.nottingham-http-link-header">[I-D.nottingham-http-link-header]</a></td>
<td class="author-text">Nottingham, M., &ldquo;<a href="http://www.ietf.org/internet-drafts/draft-nottingham-http-link-header-03.txt">Link Relations and HTTP Header Linking</a>,&rdquo; draft-nottingham-http-link-header-03 (work in progress), November&nbsp;2008 (<a href="http://www.ietf.org/internet-drafts/draft-nottingham-http-link-header-03.txt">TXT</a>).</td></tr>
</table>

<a name="anchor14"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.A"></a><h3>Appendix A.&nbsp;
Acknowledgements</h3>

<p>
        The author acknowledges the contributions of [Ed: P. Buchheit should edit this section].
      
</p>
<p>
        The editor would like to thank Adewale Oshineye for publishing
        an earlier interpretation of the SUP specification that helped
        form the basis for this document.
      
</p>
<a name="rfc.authors"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<h3>Authors' Addresses</h3>
<table width="99%" border="0" cellpadding="0" cellspacing="0">
<tr><td class="author-text">&nbsp;</td>
<td class="author-text">Paul Buchheit</td></tr>
<tr><td class="author-text">&nbsp;</td>
<td class="author-text">FriendFeed</td></tr>
<tr><td class="author" align="right">Email:&nbsp;</td>
<td class="author-text"><a href="mailto:[Ed: Paul -- do you want your email published?]">[Ed: Paul -- do you want your email published?]</a></td></tr>
<tr><td class="author" align="right">URI:&nbsp;</td>
<td class="author-text"><a href="http://paulbuchheit.blogspot.com/">http://paulbuchheit.blogspot.com/</a></td></tr>
<tr cellpadding="3"><td>&nbsp;</td><td>&nbsp;</td></tr>
<tr><td class="author-text">&nbsp;</td>
<td class="author-text">DeWitt Clinton (editor)</td></tr>
<tr><td class="author-text">&nbsp;</td>
<td class="author-text">Google</td></tr>
<tr><td class="author" align="right">Email:&nbsp;</td>
<td class="author-text"><a href="mailto:dewitt@unto.net">dewitt@unto.net</a></td></tr>
<tr><td class="author" align="right">URI:&nbsp;</td>
<td class="author-text"><a href="http://unto.net/">http://unto.net/</a></td></tr>
</table>
</body></html>
